Add a LoggerMessage-based ToolCallCompleted log at Information level that
captures the tool name on successful tool call completion, matching the
existing ToolCallError pattern for failures.

Also add the log call to the task-augmented tool execution path.

Add test Logs_Tool_Name_On_Successful_Call to verify the new log message.

Co-authored-by: halter73 <54385+halter73@users.noreply.github.com>

Address reviewer feedback:
- Include CallToolResult.IsError as a parameter in the ToolCallCompleted
  log message (@halter73)
- Always log ToolCallCompleted when InvokeAsync doesn't throw, including
  when IsError=true (@halter73)
- Skip ToolCallCompleted in outer handler for task-augmented calls to
  avoid double-logging; the async ExecuteToolAsTaskAsync logs separately
- Add ReturnIsError tool for testing IsError=true without throwing
- Add Logs_Tool_Name_With_IsError_When_Tool_Returns_Error test
- Add TaskPath_Logs_Tool_Name_On_Successful_Call test
- Add TaskPath_Logs_Tool_Name_With_IsError_When_Tool_Returns_Error test
- Add TaskPath_Logs_Error_When_Tool_Throws test
- Update tool count assertions for new ReturnIsError tool

Co-authored-by: halter73 <54385+halter73@users.noreply.github.com>

Use GetTaskResultAsync to wait for task completion instead of arbitrary
Task.Delay(500) calls, making tests deterministic and faster.

Co-authored-by: halter73 <54385+halter73@users.noreply.github.com>

…n types

Remove the exception type filter (when clause) from the error logging
catch blocks for prompts and resources, and add a second catch block
for tools, so that OperationCanceledException and McpProtocolException
are also logged with tool/prompt/resource names. Behavior is unchanged:
tools still produce IsError results for non-cancel/non-protocol
exceptions, and prompts/resources still rethrow all exceptions.

Add tests verifying error logging and LogRequestHandlerException for
OperationCanceledException and McpProtocolException in all three
handler types.

Co-authored-by: halter73 <54385+halter73@users.noreply.github.com>

…dException

When a tool throws OperationCanceledException but the passed-in
cancellation token is not canceled, produce an errored CallToolResult
(IsError=true) instead of rethrowing. This prevents non-user-initiated
cancellations from propagating as protocol errors.

User-initiated cancellations (where cancellationToken.IsCancellationRequested
is true) still rethrow as before.

Co-authored-by: halter73 <54385+halter73@users.noreply.github.com>

Consolidate the OperationCanceledException, general exception, and
fallback catch blocks into a single catch (Exception e) with:
- One call to ToolCallError
- Conditional rethrow for user-initiated cancellation or McpProtocolException
- One return of errored CallToolResult for everything else

Co-authored-by: halter73 <54385+halter73@users.noreply.github.com>